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1. PREFACE - RELATED REPORTS 


This report provides an overview of the Socrates? Munich pilot. The focus lies on the description of 
the use cases, the technical and functional design, as well on the operational period and the analysis 
of the pilot data. 


The evaluation of the Munich pilot and the drawn conclusions based on the analysis is not part of this 
report, but can be found in the evaluation report of Activity 8. 


2. ORGANISATIONAL SET-UP 


Based on the use cases and their functional designs defined in Activity 3, two working groups had 
been set up to elaborate the Munich pilot. 


e Smart Destination: 
o Involved partners: BrandMKRS, Be-Mobile BMW, and the Bavarian Road Authority as 
associated partner 
e Road Works 
o Involved partners: Be-Mobile, MAPtm, TomTom and the Bavarian Road Authority as 
associated partner 


In the following chapters a detailed description for each of the two uses cases is given. 


3. INTRODUCTION — SMART DESTINATION 


In Activity 3 the functional design of the use case Smart Destination has been described and approved 
by the Socrates*° steering group in October 2018. In Activity 6 this functional design is elaborated in 
more detailed. Based on this latter design the pilot was developed. 


This document presents the functional and technical designs of the Socrates?° use case ‘Smart 
Destination’ and ‘Road Works’ in the pilot site Munich. It is a report on the technical design and the 
changes made on the traffic centre (6.1), the realization of intermediaries (6.2), the changes on back 
offices (6.3) and end-user applications (6.4) and the system integrations tests (6.5). 


The technical architecture of these Use Cases includes sequence diagrams, user stories and interface 
descriptions. These are elaborated for each cooperation model, based on the functional design as 
described in Activity 3. 


3.1 Use case description — Smart Destination 


The Socrates?! Use Cases Smart Destination deployed in the Munich region are related to two 
different event locations: 


e Allianz Arena 
e Messe Munchen 


Main problem 


The main problem at events at the Allianz Arena and the Messe Munchen is the sub-optimal traffic 
inflow before and during an event and the sub-optimal parking choice distribution in the area. 


- Many road users don’t know exactly which exit to take to reach the event area nor where to park 
best. 

- Non-event visitors who drive in the area of the event often do not know that an event takes place 
and are stressed by the heavy traffic that is generated by the event. 


The problems are caused by: 
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- Visitors have little knowledge about parking location A occupancy 

- Routing services do not generally consider parking guidance & occupancy 

- Routing services do not generally consider recommendations of road authorities to optimize the 
inflow 


Mission 
The mission of the use case is to provide better information for: 


e Event visitors with detailed information which route to take and where to park best. 
e Non-event visitors, that drive in the area of the event, to inform them on the event related 
traffic conditions and recommend them to avoid the area. 


By means of execution and validation of this use case, it contributes to the overall goals of Socrates: 


e Testing of public private cooperation and new business models; 
e Testing the effectiveness of Traffic Management 2.0 by communicating directly with the end 
user. 


Allianz Arena - local context 
Rough sketch of the arrival options from the north: 


e A9 (blue) 
e A92 (yellow) 
e B13 (purple) 





Garching 
i Munchen 


FIGURE 1. ARRIVAL OPTIONS TOWARDS THE ALLIANZ ARENA FROM THE NORTH 
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Parking garages (capacity 8717 veh) 






— P1 2880 spaces (500 for disabled persons) 
— P2 3000 spaces 

— P3 2837 spaces 

— 1200 VIP spaces 

— 350 coaches 





FIGURE 2. OVERVIEW OF THE DIFFERENT PARKING SPACES AT THE ALLIANZ ARENA 
(SOURCE HTTPS://ALLIANZ-ARENA.COM/EN/MATCHDAY/HOW-TO-REACH-US-AND-PARKING, 12.10.2020) 


Messe München / Munich Trade Fair- local context 


The Messe München, with roughly 40 fairs focusing on new technologies, consumer and investment 
goods, belongs to the globally leading fair associations. In addition, there are 14 international leading 
fairs taking place in Munich. 


The fair location Munich has 16 halls with an exhibition area of 80,000 m? before 2018, 2 halls will 
provide an additional 120,000 m?. Moreover, the fair already has Germany’s fair locations’ biggest 
outdoor area with 425,000 m2. 


The Messe Munchen has enough parking spots for cars and busses. At specific events, a guide 
system lead to them. The visitor is allowed to start parking two hours before and must have left the 
parking space two hours after the event. 


Parking structure ‘West: In the parking structure there are 14,000 parking spots. From there, the ICM 
and the fair building can be directly accessed. The parking structure is only open during the events. 
Daily fee of 10 €. 


Parking structure park & ride ‘Messestadt Ost’: The parking structure does not belong to the fair site, 
yet it can be used by visitors. On 1050 spots, one can park for 10 € a day. 


Parking spots at North entrance: For 8 €/day, one can park outside. 
(source: https://en.instaff.jobs/exhibitions/locations/trade-fair-m%C3%BCnchen, 12.12.2019) 


Rough arrival options from the north: 


e A99 + A94 (purple) 
e A9 + B2R (blue) 
e A99 + St2082 (yellow) 
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FIGURE 3. ARRIVAL OPTIONS TOWARDS THE MESSE MÜNCHEN FROM THE NORTH 
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FIGURE 4. EXAMPLE OF A STRATEGY TOWARDS THE MESSE MÜNCHEN FROM THE NORTH 
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FIGURE 5. OVERVIEW OF THE DIFFERENT PARKING LOTS AT THE MESSE MÜNCHEN 


(SOURCE HTTPS://WWW.INSTAFF.JOBS/MESSEN/STANDORTE/MESSE-M%C3%BCNCHEN#ANFAHRT, 


12.10.2020) 


3.2 Functional overview 


Changes in relation to Activity 3 — functional design 


The table below contains an overview of the changes made during the further development of the Use 


Case in Activity 6, in relation to the Activity 3 functional design. 


Activity 3 Activity 6 


FIGURE 6. ACTIVITY 3: PART 3: SOCRATES’ SERVICES FOR SMART DESTINATION UC 


3.1 System overview No changes 

3.2 Cooperation Model Cooperation Model 2 No changes 

3.3 Roles No changes 

3.4 Intermediary No changes 

3.5 Actors BrandMkrs, Be-Mobile, BMW 

3.6 Pre/post-conditions Due to the Corona crisis no events with a 


larger group of visitors/ greater audience 
take place since 03/2020 till end of 2020. 
Thus, targeting/ recruiting/ interviewing of 
real end users was not feasible. A real 
piloting could not be executed. 
Compensation via friendly user tests. 


3.7 Sequence diagram No Changes 
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Staged deployment of functionalities 


The operational stage was planned from January 2020 to June 2020. The operational period was 
extended to end of 2020 due to the Corona crisis and the lack of big events. A detailed description of 
the deployment and recruitment adaptions is described subsequent. 


Allianz Arena 


FIGURE 7. DEPLOYMENT AND FUNCTIONALITIES ALLIANZ ARENA 
Initially: 
e Every two weeks at soccer games in the during the soccer league 


e EURO2020: 16/21/ 26 June + 03 July 2020 
> All events are skipped or without an audience due to the Corona Crisis 





Events 











Below an overview of scheduled soccer games in the Allianz Arena during the pilot phase is shown. 


BUNDESLIGA | 9. SPIELTAG 


Se FC Bayern München 
SA | 26.10.2019 | 15:30 Uhr 


Wæ 1. FC Union Berlin 
Olympiakos Piräus 
Ei Borussia Dortmund 


erm Bayer 04 Leverkusen 


CHAMPIONS LEAG 4. SPIELTAG 
deg user l v S P é FC Bayern München 
BUNDESLIGA II SPIEL AG FC Bayern München 
SA | 09.11.2019 8:30 Uhr 

BUNDESLIGA | 13 SP H AG FC Bayern München 
SA | 30.11.2019 | 18:30 Uhr 
CHAMPIONS LEAGUE | 6. SPIELTAG 


nian FC Bayern München 
MI | 11.12.2019 | 21:00 Uhr 


Dg Tottenham Hotspur 


8 FC Bayern München 


a SV Werder Bremen 





UNDESLIG 
20.12 - 22 


UNDESLIGA | 19. SPIELTAG 
24.01 - 27.01.2020 





UNDESLIGA | 





UNDESLIGA | 
1.04 - 13.04.202 








FC Bayern München 


FC Bayern Miinchen 


FC Bayern München 


FC Bayern Munchen 


FC Bayern Munchen 


CEE E IE IE IE EOE 6 


FC Bayern München 


FC Bayern München ta 
FC Bayern München ta 
FC Bayern München 





( WwW VfL Wolfsburg 


® FC Schalke 04 


Sé RB Leipzig 


~- SC Paderborn 07 


© FC Augsburg 
Eintracht Frankfurt 


Fortuna Düsseldorf 


® Borussia Mönchengladbach 


4 Sport-Club Freiburg 


FIGURE 8. SOCCER GAMES AT ALLIANZ ARENA (STATUS OCT 2019) 


Some important events in the Allianz Arena would have been the soccer matches for EURO2020 
planned for the16th / 21st / 26th of June and 3rd of July 2020. Initially it was planned that the 
Socrates?- services will also be deployed during these events. But due to the Corona crisis the 
EURO2020 was shifted to 2021 and therefore no event took place during the pilot phase. 
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Overall, due to the Corona crisis no events with a larger group of visitors/ greater audience took place 
from 03/2020 till end of 2020 in the Allianz Arena. Thus, targeting/ recruiting/ interviewing of real end 
users was not feasible. A real piloting could not be executed. A compensation was made via friendly 


user tests. 


Messe Munchen 


FIGURE 9. DEPLOYMENT AND FUNCTIONALITIES MESSE MUNCHEN 





Events 








=> See list below of scheduled trade fairs 


> Due to the Corona crisis trade fairs are cancelled or without a greater 


amount of visitors. 








Here is shown an overview of major trade fairs at Messe Munchen in 2020 including the number of 
expected visitors (status Jan 2020): Initially it was planned to provide the Socrates?° service to users 
of at least two of these major trade fairs. But due to the Corona crisis all of these events had been skip 
or limited to a small non-public visitor group. 


FIGURE 10. SCHEDULED MAJOR TRADE FAIRS AT MESSE MUNCHEN IN 2020 (STATUS JAN 2020) 











Name Topic Start End Visitors 
Opti Optics Fr, 10. Jan 09:00 So, 12. Jan 18:00 28.000 
ISPO Sports So, 26. Jan 09:00 Mi, 29. Jan 18:00 85.000 
Inhorgenta Jewelery Fr, 14. Feb 09:00 Mo, 17. Feb 18:00 27.000 
Free Travel Mi, 19. Feb 09:00 So, 23. Feb 18:00 150.000 
Internet World Expo E-commerce Di, 10. Mrz 09:00 Mi, 11. Mrz 18:00 20.000 
Garten München Gardening Mi, 11. Mrz 09:00 So, 15. Mrz 18:00 110.000 
Internationale 

Handwerksmesse Construction, Crafts Mi, 11. Mrz 09:00 So, 15. Mrz 18:00 110.000 
Analytica Bio technology Di, 31. Mrz 09:00 Fr, 3. Apr 18:00 36.000 

environmental 

IFAT technologies Mo, 4. Mai 09:00 Fr, 8. Mai 18:00 150.000 
Automatica Robotics, automisation Di, 16. Jun 09:00 Fr, 19. Jun 18:00 45.000 
Intersolar Solar energy Mi, 17. Jun 09:00 Fr, 19. Jun 18:00 50.000 
expopharm Medicin Mi, 7. Okt 09:00 Sa, 10. Okt 18:00 25.000 
electronica Comsumer electronics Di, 10. Nov 09:00 Fr, 13. Nov 18:00 82.000 





3.3 Active partners 


Four Socrates?-° partners and one associated partner had been active in the Smart Destination use 


case in Munich. 


Bavarian Road Authority — Role Data provider / Road Authority 


The Bavarian Road Authority wants to be a good host for inhabitants and visitors alike. As a public 


data provider and road authority | want to recommend reliable data to road users which route to 


choose best towards an event and where to park preferable at the event location or even where to 
avoid heavy jammed areas due to an event. | want to achieve less traffic jams, less parking search 
traffic and stress reduction to the road users due to the increase of event specific information. Above 


all, the use case should contribute to improve the overall traffic flow. 
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MDM - national data access point 


As the national data access point in Germany | receive strategic route and parking lot data, in this 
case from the Bavarian Road Authority about the Alliance Arena in Munich and the Messe München 
(trade faire). Thereafter | enrich the data flow and make this information public available in standard 
European formats. | want to improve the availability, quality and accessibility of public data. 


End user Service provider 


As a Service provider, | want to receive up-to-date and accurate data on strategic routes and 
recommended parking lots regarding a specific event in standard formats. | want to provide most 
accurate guidance and parking information on events to my users, so that they experience a satisfying 
journey towards their event. 


3.4 Generic description of end user services 
End user service by BrandMKRS 


The BrandMKRS Smart Destination service in Munich aims at providing a routing advice to event 
visitors. First step is to target and approach users on social media, have them ‘opt-in’ to register, and 
provide them with relevant information. Then, at the day of the event, provide the user a route with the 
best access to take. 


“68 


@ google.ni 
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e 
. 48.2357495, 11.6365173 
© ra i 
"ëm Eier 409650. 
im 12 min 
er g A “ u 
` _ à 
München De 11.6" o 2 
200 Oe Google = 
= Q 
em 
12 min k 12 min 





FIGURE 11. SERVICE SCREENS TOWARDS THE MESSE MÜNCHEN OF THE END USER SERVICE OF BRANDMKRS 


Service by BMW Group 


The approach taken to realize the Socrates?-° vehicle prototype is an “Offboard-Routing”, meaning the 
route for the vehicle is no longer calculated by the internal navigation system of the vehicle, but by an 

external server. The communication is done via a built-in mobile phone connection. This approach is a 
common realization which is also already in use in series production vehicles. This is an essential fact, 
as the prototype was used by normal series production vehicles of customers. 


The normal setup was extended by a so called “vehicle app”, which is essentially only an application 
running on the vehicle’s onboard unit. Those vehicle apps can be pushed to defined vehicles via over- 
the-air updates and only need to be downloaded by the vehicle to get the prototype ready. 
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request information 
via mobile network 


BMW Routing 


Backend 


new route 
information 





FIGURE 12. BMW VEHICLE — BACKEND INFORMATION EXCHANGE 


This described vehicle application is used to send detailed and personized information to a vehicle 
and display it instantly in the car. The implementation is realized via a pull mechanism, where all 
information is kept in the backend and vehicles make requests for new information to be displayed. 
The backend decides conditionally when to release new information. When asking for new information 
the vehicle transmits its current position, enabling the backend to decide geographically when to send 
new information. 


Information 4 
/ d 
DO e ——= BMI = 
s 4 
Fm e | Vehicle 1 
u Vehicle 2 


Vehicle 1 









infos given 


No information 
for this car 


Vehicle1 — position — infos 
No information BMW . 
at this position Backend 





FIGURE 13. VEHICLE APP AND BMW BACKEND COMMUNICATION TRIGGERED BY GEO LOCATION 


This picture above shows how the developed vehicle app and the backend work together. The 


backend service only gives information to specific vehicles and only if they are near a specific location. 


Information can also be broadcasted to all vehicles, or can be send to a specific vehicle independent 
from its position. 


The combination of these two services — the router running on backend servers and the vehicle app to 
display additional information in the car are the two core components used to realize all prototypes 
and demonstrators in all Socrates?° pilot cities. 


BMW Backend 


The BMW backend itself can be structured into several subcomponents again. The picture below 
shows those different components. 
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BMW Backend 










Information- 
Source 






Traffic- 
Strategies 





Importer 


Notification- 
Service 


Routing-Backend 


FIGURE 14. COMPONENTS OF THE BMW BACKEND 


The importer is responsible for fetching or receiving information from 3rd party information sources, 
such as intermediaries or authorities. As shown in the picture above there are several importers, as 
different protocols or publishing strategies are being used. To have aclean and maintainable 
infrastructure, separate importers have been created for different protocols. 


After receiving the information, the importer passes it on to the strategy store. This store holds all 
currently active strategies, from all different sources in a unified format. The importer can also update 
or invalidate strategies if this is applicable. 


The BMW routing backend checks the strategy store for active strategies. Based on this information it 
calculates alternative routes and gives information about the intended behaviour for the fleet to the 
notification service. Whenever there is an active strategy, the routing backend produces a so called 
“trigger-screen”. The trigger-screen is a message which is sent to the car, via the notification service, 
to ask the driver, if he wants to take an alternative route. The appearance and content of this trigger- 
screen is dependent on the strategy. 


The notification service is responsible for the communication with the vehicles as they constantly ask if 
there is any information that should be displayed to the driver. The notification service also receives 
the answers from the drivers, e. g. when they were asked if they would like to take a strategic 
alternative route. If they acknowledge, this information is passed on to the routing backend. The 
routing backend then calculates an alternative route based on the currently active strategies. The 
details of this route, including information that needs to display to the vehicle are passed back to the 
notification services. The notification service now creates vehicle specific information screens which 
are provided along the route. 


This overarching architecture has been implemented for all of the Socrates? pilot cities. The 
notification service and the strategy store could be kept generic from the specifics of the pilot sites. 
The routing backend was fed with some configuration for each pilot site, but its core logic was 
independent and identically for all pilot sites. Whilst most of the components could be used without 
adaptation for all pilot sites, especially the importer had to be tailored to the specific use case. The fact 
that the information from many different sources could not be collected in the same fashion, is not very 
surprising. However, during the implementation of the pilot sites, the usage of standardized protocols 
and national distribution hubs was always favoured, to ensure a scalability from single suppliers to a 
larger extent. 


BMW Frontend 


The Service of BMW Group provides the information via a vehicle app. A pop-up occurs in the main 
display if the user passes specific geofence areas in the surroundings of the event and on the 
strategic route segments towards the event area. This is triggered by the BMW Backend as described 
before. The user is asked whether he wants to follow the strategic route advice towards the event 
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area. If he accepts, further in car pop-ups occur and guide him on the strategic streets towards the 
preferred parking lot as shown in Figure 15. 


Strategic route recommend to park 
at Messe Munchen. 
Follow strategic route? 


f Messe München 
No ` 


A Managed City Drive 
Take next exit for "Messe / ICM". 


You have arrived at "Messe 
München", 


Please follow the local sings to 
"Parkhaus 5". 


Did you like the Managed City Drive 
Service? 


No 





FIGURE 15. SERVICE SCREENS SEQUENCE TOWARDS THE MESSE MÜNCHEN OF THE IN VEHICLE END USER 
SERVICE OF THE BMW GROUP 
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FIGURE 16. EXAMPLE OF THE BMW SERVICE ON THE IN VEHICLE DISPLAY 


re Socrates? PILOT IN THE REGION OF MUNICH 14-6-2021 


the European 
Commission 


Service by Be-Mobile 


The Be-Mobile Smart Destination service for the Messe München aims at providing a routing advice to 
event visitors via the Flitsmeister navigation driver companion service. The use-case starts for the 
end-user when she puts in Messe Munchen as destination in the Flitsmeister application. 


e The end-user is offered the fastest route to Messe München. In the route choice screen, a 
pop-up will be shown which asks the end-user whether she would like to have parking 
guidance. 





< Messe München, Am Messeturm,... + 


Parkeren bij je bestemming? 
Tik voor parkeerbegeleiding 


Nurnberg 


Heilbrann 


Q Ingolstadt 


Reg ens 





FIGURE 17. EXAMPLE OF THE FLITSMEISTER SERVICE 


e If the end-user accepts the parking guidance (by clicking on the pop-up), she will be shown a 
screen where the parking options will be shown. In the case of an event at the Messe 
Munchen (i.e. when the SD Munich use-case is active), the presented parking option will be 
aligned with the parking strategy provided by the MDM. 
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e Ifthe end-user clicks on the parking, she will be presented with some information (such as 
travel time from the parking to the Messe Munchen, and parking occupancy). She can then 





€ Messe München, Am Messeturm,.. + 


Q 


Paoi, 





Peaks o 
Tafa 


Parkplatz P3 7! 
Tik voor details 17 min 


FIGURE 18. EXAMPLE OF THE FLITSMEISTER SERVICE 


choose to start the route towards that parking. 


Melden 





Parkplatz P3 z- zB = 


A " a 
RK Looptijd 17 min = 


E Parkeerplaatsen 100 totaal 
Start route ` 3 


wees" 





E) cz 
FIGURE 19. EXAMPLE OF THE FLITSMEISTER SERVICE 
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4. INFORMATION ARCHITECTURE - SD 


4.1 Sequence diagram 


Manage event 
and parkinginfo 
in the OMC 















Manage event 
a and traffic state 
info 












Distribute route + parkin 
lot advice/ strategies 


Collective route 
advice highways + 
towards a specific 
parking lot 









Distribute parking 
lot strategy; 
Corresponds 
1-to-1 to a RA 
strategy 


Balancing individual 
and collective goals 
in route calculation 







Provide individual 
route advice 
regarding strategies 
+ parking lot 






FIGURE 20. SEQUENCE DIAGRAM SMART DESTINATION MUNICH 


4.2 Processes and interactions 


The information architecture (IA) is an elaboration of the sequence diagram (see 2.1). It describes the 
processes and interactions between processes. The processes are functional and general conducted 
by one stakeholder as an internal process. A process receives and collects data, enriches the data 
and produces information as a product. Information is sent via protocols to other processes in the 
architecture. 


Step 1: Manage Event and Parking Information + distribute strategy 


The event manager collects and enriches the parking info and sends it through to the Road Authority. 
In the Operation Management Center (OMC) a parking operator of the Munich trade fair and an 
operator of the Bavarian Road Authority is present. 


Step 2: Manage Event and Traffic State Info + translate to MDM-DATEX2 


The operators in the OMC will have the overview on Traffic State and Parking Info and decide jointly 
on suitable information and routing strategy. The Bavarian Road Authority executes its traffic 
measures and translates these to service requests in MDM-DATEX2 format for Service Providers. 
Within Socrates? the Bavarian Road Authority has implemented in the trade fair strategies a one-to- 
one relation from the main road routes towards the specific parking lot. Thus, in one service request 
the recommended route and the preferred parking lot is incorporated. Also the cause of the strategy is 
implemented. No extra connection between the event manager/ OMC parking operator and the 
intermediary or service provider is needed. 


Step 3: Service Request - Distribute road and parking lot advice (via the intermediary MDM) 


The Bavarian Road Authority sends out the service request via the German Access Point MDM as an 
intermediary The MDM-DATEX2 profile used is based on former developments and projects. 
Exceptions are written in OpenLR. 


Step 4: Providing service / type of service (SP) 


The Service Providers have a connection to the MDM. If they receive a service request, they adapt it 
to their service and provide the information to the road users (see chapter 3.4 on end user services). 


the European 
Commission 


es apa by Socrates? PILOT IN THE REGION OF MUNICH 14-6-2021 


Event Manager Im] 


Step 5: Service activation 


Internal process of the service provider: Services providers can accept or decline the service requests. 
If they accept, the communicated strategy incorporating the preferred parking lot is translated in a 
recommendation of where to drive for the end user. 
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5. SYSTEM ARCHITECTURE - SD 


5.1 System overview 


Data Providers Intermediary 









Aor Option 1: MDM 
sources Pavita Apps etc. 
Actual BavrRA | COD TT 
; Strategy TomTom Apps etc. 
Strategy for parking lots all , Wë DEE EA Option 2: peer to peer 


corresponds 1-to-1 to a Ba 


no details about occupancy BrandMKRS Apps etc. 





data Allianz measurements + 
strategy storage aggregated leve 
sources Arena pa ropot 


actual parking 
lots strategy 





data Messe 
sources Munchen 


actual parking 
lots strategy 





—> Socrates interface 


—- intemal interface 


FIGURE 21. SYSTEM OVERVIEW SMART DESTINATION MUNICH 


5.2 Interfaces 


This section contains detailed information about the interfaces and the information exchanged via 
these interfaces. 


MDM protocol 

The existing MDM-DATEX2 protocol is used (MDM: Datenmodell für strategiekonformes Routen 
Version 01-00-00 — 05|2012) for option 1, the communication via the MDM. A peer to peer exchange 
(option 2 in Figure 21) was not further elaborated within Socrates@°. 


This interface is minimally required to build a functional system. Others can ‘subscribe’ to consume 
this information as well for own information purposes. 


The reason for the measure and related situation is included based on designated fields of MDM- 
DATEX2. 
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Bayerische Straßenbauverwaltung - Zentralstelle für 
Verkehrsmanagement 


Internetseite: http://abdsb.bayern.de | 




































































ID Publikations-Name Gültigbis Rech. Aktiv Aufgabe Konfiguration 
2522000 Strategisches Routing in der WWW Netzmasche A9-A92- 31.12.2017 si vY Details 
A99 
2523000 Stellzustände der SBA AQ Fischbach 31.12.2017 V v Details 
2523001 Stelizustande der WWW Netzmasche A9-A92-A99 31.12.2017 vV v Details 
&<ı23 
AGB 
en Publikation anlegen Subskription anlegen Aufgaben 
Rechtliche Hinweise 
Kontakte 
opas 
© MDM-Portal 2010-2016 
FIGURE 22. SCREENSHOT OF THE MDM-PORTAL 
name type definition comment / example origin 
id String An ID actionPlanldentifier in MDM MDM 
HEEN String A descriptive name MDM 
agement 
Defines geolocations which a route 
trigger(s) Open H | needs to surpass such that a strategy MDM 
applies to him/her 
Original route where an 
route(s) OpenLR Original routes. Have several sub- alternative route has been MDM 
properties such as georeference etc. defined to replace this original 
route 
Alternative route in order to 
Alternative routes. Have several sub- 
alternative route(s) | OpenLR reduce / prevent usage of MDM 
properties such as georeference etc. Sp 
original route 
additionalManage For each route several reasons can be | e.g. capacitiesAvailable, 
Enum ; . MDM 
mentTypeEnums given extendedGreenPeriod ... 
Object that describes traveltimes for the 
travelTimeData |Time _| utes depending on the vehicle type MDM 
and possibly including a prediction 
trend 
weightingAndVehi | Classifica | Describes types of vehicles which are 
shar ; (e MDM 
cleClassification tion allowed to/should take a specific route 
{environmental, manual 
cause Enum Contains the reason intervention, traffic conditions, | MDM 
incident, ...} 
at ; Explanation of the reason towards end |"Prevent usage of inner-city 
auseDesenplion.- yaning users roads and use the ring road" MENI 
operatorActionStat E Status of the operator's action if {beinglmplemented, 
üs num applicable implemented, MDM 
beingTerminated} 
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Equi Enum Additional information about the TMP {advisory, mandatory} 


complianceOption 


MDM 





indicatedEndPoint | Open DH | Gives the end point of the route E.g. the parking location 


new 





preferredNetworkT 
oBeUsedinOrderT 
oPreventDriversSo 
mewhereElse 


Needs attention in order to prevent 
Open DH people of driving into the area while the 
ring road should be used 

















new 





T<soap:Envelope xmins:soap="http: //schemas.xnlsoap.org/soap/envelope/"> 
v<soap:Body> 
w<d2LogicalNodel xmlns="http: //datex2.eu/schema/2/2_0° xmins:xsi="http: //www.w3.org/2001/XMLSchema-instance” modelBaseVersion="2" xsi:schemaLocation="http: //datex2.eu/schema/2/2_0 
http: //sdbby.heuboe.de:11447/d2Schema/StrategicRouting.xsd"> 
v <exchange> 
v<supplierIdentification> 


<country>de</country> . 
ee EN EE EES _—_———— | 
dE upplier 
</exchange> 
v<payloadPublication xsi:type="SituationPublication” lang="de"> 
<pabl icat LonTime>2020-04~-27716 158100402 :00</publ icat ionTime> 
» <publicationCreator> 


</publicationCreator> e 
v<situation id="S1587736980869" version="1"> Ve rs | 0 n 
<situationVersionTime>2020-04-24T16:03:00+02:00</situationVersionTime> 
» <headerInformat ion> 


</headerInformation> 
y<situationRecord xsi:type="GeneralNetworkManagement” id="R1587736980869" version="1"> 
<situationRecordCreat ionTime>2020-04-24T16:03:00+02:00</situationRecordCreationTime> 
<situationRecordVersionTime>2020-04-24716 :03:00+02:00</situationRecordVersionTime> eH 
<probabilityOfoccurrence>certain</probabilityOf0ccurrence> a | it 
v<validity> 
<validityStatus>definedByValidityTimeSpec</validityStatus> 
v<validityTimespecification> 
<overallStartTine>2020-04-24716:03:00+02:00</overallStartTime> 
<overallEndTine>2020-04-27717:00:00+02:00</overallEndTime> 
</validityTimespecification> 


</validity> 
or ause 


¥<causeDescription> 
v<values> 
<value lang="de">Optimierte Zielführung zu den Parkplätzen Messe</value> 
<value lang="en">improved routing to parking area Munich Trade Fair</value> 
</values> 
</causeDescription> 


ae Strategy-ID 


» <groupOfLocations xsi:type="Area"> 








</groupOfLocat ions> 

<act ionPlanIdentifier>S-14e</actionPlanIdentifier> 

<operatorActionStatus>implemented</operatorActionStatus> 

<complianceopt ion>advisory</complianceopt ion> = = 

<generalnetworkManagenentType>other</generalNetworkNanagenentType> escri tion 

¥<generalNetworkManagenentExtension> 

¥<generalNetworkManagementExtended xsi: type="StrategicRouteManagement "> 
v <nameOfRouteManagement> 
v<values> 
<value lang="de">A94 West - Riem 2 Parkhaus West</value> 

</values> 


</nameOfRouteManagenent> - 

v<triggerorigin> rigger 
</lecation> 
</triggerOrigin> 

v<route> 
¥<nameOfRoute> 
> <values> e Route 
</values> 

</nameOfRoute> 

<originalRoute>true</originalRoute> 

» <weightingAndVehicleClassification index="0"> 


</weightingAndVehicleClassification> 


FIGURE 23. EXAMPLES OF THE MDM-DATEX2 PROFILE 


Within Socrates? the MDM-DATEX2 profile was enriched with the route cause to improve the 
interpretation of the strategy and a unique strategy ID. 
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- <cause xsi:type="NonManagedCause' > 
- <causeDescription> 
- <values> 
<value lang="de">Optimierte Zielfiihrung zu den Parkplatzen Messe</value> 
<value lang="en">improved routing to parking area Munich Trade Fair</value> 
</values> 
</causeDescription> 
<causeType>other</causeType> 
</cause> 
+ <groupOfLocations xsi:type="Area"> 
<actionPlanIdentifier>S-14c</actionPlanIdentifier> 
<operatorActionStatus>implemented</operatorActionStatus> 
<complianceOption>advisory</complianceOption> 
<generalNetworkManagementType>other</generalNetworkManagementType> 
- <generalNetworkManagementExtension> 
- <generalNetworkManagementExtended xsi:type="StrategicRouteManagement"> 
- <nameOfRouteManagement> 
- <values> 
<value lang="de">A94 West - Riem 2 Parkhaus West</value> 
</values> 


FIGURE 24. EXAMPLES OF MDM-DATEX2 PROFILE, ENRICHED OF THE ROUTE CAUSE AND ID 


In addition, the different strategies are fixed numbered and stated in the MDM-DATEX2 protocol. 
Thus, the interpretation of the strategies on the service provider site could be done via a fixed look up 
table (especially for test cases and as a fall back solution). 


FIGURE 25. LOOK-UP TABLE WITH ID AND DESCRIPTION OF ALL STRATEGIES TOWARDS THE MESSE MUNCHEN 


ID (Action Plan Identifier) Route number PDF frequently used Name (Name of Route) 


S-09 1 A99 Nord via B471 Aschheim 
S-10 2a D A99 Nord via Kirchheim 
S-11-a 3a x A94 Ost - Feldkirchen West Freigelände 
S-11-b 3b D A94 Ost - Riem Parkhaus West 
S-11-c 3c A94 Ost - Am Moosfeld Parkhaus West 
S-12-a 4a x A99 Süd - Feldkirchen West Freigelände 
S-12-b 4b D A99 Süd - Riem Parkhaus West 
S-12-c 4c A99 Süd - Am Moosfeld Parkhaus West 
S-13-a 5a x A99 Nord-Feldkirchen West Freigelände 
S-13-b 5b D A99 Nord-Riem Parkhaus West 
S-13-c 5c A99 Nord-Am Moosfeld Parkhaus West 
S-14-a 6a A94 West - Am Moosfeld Parkhaus West 
S-14-b 6b A94 West - Riem 1 Parkhaus West 
S-14-c 6c x A94 West - Riem 2 Parkhaus West 
S-14-d 6d x A94 West - Feldkirchen West Freigelände 
S-15-a 7a A9 - Mittlerer Ring Nord - Am Moosfeld Parkhaus West 
S-15-b 7b AQ - Mittlerer Ring Nord - Riem 1 Parkhaus West 
S-15-c 7c x AQ - Mittlerer Ring Nord - Riem 2 Parkhaus West 
S-15-d 7d x AQ - Mittlerer Ring Nord - Feldkirchen West Freigelände 
S-16-a 8a A8 - Mittlerer Ring Sued - Am Moosfeld Parkhaus West 
S-16-b 8b A8 - Mittlerer Ring Sued - Riem 1 Parkhaus West 
S-16-c 8c x A8 - Mittlerer Ring Sued - Riem 2 Parkhaus West 
S-16-d 8d x A8 - Mittlerer Ring Sued - Feldkirchen West Freigelände 
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6. 
6.1 


INTRODUCTION — ROAD WORKS 


Use case description 


The use case Road Works focusses on data quality improvement in the live stream as described and 
finalized in activity 3 for Road Works use cases. The use case is to be deployed in the following pilot 


sites; 


Antwerp 
Amsterdam 
Munich 


The basis for all Pilot sites is the same and resembles the use case description as for Antwerp. The 
pilot sites Munich and Amsterdam build upon this basis to both incorporate a pilot site specific 
detail/extension. 


The pilot site Munich will make use of Truck Mounted Attenuators. These TMA are deployed on the 
road to warn traffic for an oncoming Road works zone and project the people working in the RW-zone. 
The TMA rely their live location and shown traffic warning to the central system. This information 
includes location GPS and direction of travel shown (pass left or pass right). This information is 
included within the available MDM-DATEX2 feed. 


In all pilot sites the assessor will investigate the quality improvement and establish the value of the full 
chain and help in deriving the win-win-win from the lessons learned. 


Road Authority: Bavarian Road Administration 


As a Road Authority, | want to provide road works data to a service provider offering a service to the 
end user. 


I collect roadworks information from various data sources. My staff is in direct contact to the 
entities executing the work. This is an existing service, nothing new needs to be developed for 
Socrates*°. 

The information is provided to a public endpoint (MDM). The data is provided in MDM- 
DATEX2 format to the intermediary. The message includes information about start time and 
end time of the roadworks as well as the location of the roadworks (set of coordinates and 
textual position information like “between Munich and Augsburg”) and if applicable additional 
information like type of road works (narrow lanes, closed lanes, closed road), reason for the 
works (bridge maintenance, resurfacing, grass cutting etc.), recommended detour for closed 
sections, height or width restrictions and phases of the works. This is an existing service, 
nothing new needs to be developed for Socrates. 

I monitor the network and validate the roadworks information based on additional data sources 
(FCD, direct contact to road maintenance offices). This is an existing service, nothing new 
needs to be developed for Socrates. 

| detect new roadworks or changes in the existing ones. This is an existing service, nothing 
new needs to be developed for Socrates. Based on this I provide updated information to the 
public endpoint. 

| receive a common roadworks picture from the intermediary in MDM-DATEX2 format. This 
message includes information about the roadworks (location, time and extend/length), the 
Universal Unique ID for the roadworks, and a confidence level. 

| validate internally against my information the common roadwork picture and if necessary, 
update my information. A team of editors is in place to receive the feedback and update the 
information. 


Identified Interface 1: MDM-DATEX2 between Bavarian Road Administration — Intermediary (From RA 
to Intermediary only) 


Objects exchanged: 
o Situational record creation time 
o Situational record version 
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Situational record first supplier version time 
Overall start date 

location OpenLR 

Network Management type 


oo00 


Identified Interface 2: TMeX between Intermediary — Bavarian Road Administration (From Intermediary 
to RA only) 


e Objects exchanged: 

Situational record creation time 

Situational record version 

Situational record first supplier version time 
Probability of occurrence 

Validity status 

Overall start date 

location OpenLR 


Service provider 


As a Service provider, | want to provide most accurate real time information on roadworks to my users, 
so that they experience a satisfying journey. 


e | collect roadworks information from various data sources. This is an existing service, nothing 
new needs to be developed for Socrates. 

e | monitor the network and validate the roadworks information based on additional data 
sources. This is an existing service, nothing new needs to be developed for Socrates. 

e | detect new roadworks or changes in the existing ones. This is an existing service, nothing 
new needs to be developed for Socrates. 

e Roadworks information are part of the incident feed that we provide to our customers through 
an API. The data is provided in MDM-DATEX2 format to the intermediary. The message 
includes information about start time and end time of the measure as well as the location of 
the roadworks 

e | receive a common roadworks picture from the intermediary in MDM-DATEX2 format. This 
message includes information about the roadworks, the trackable ID for the roadworks, and a 
confidence level. 

e | validate internally against my information the common roadwork picture and if necessary 
update my information and/or algorithms. 


Identified Interface: JSON between TomTom- Intermediary 


e Objects exchanged: 
o Situational record creation time 
Situational record version 
Situational record first supplier version time 
Probability of occurrence 
Validity status 
Overall start date 
location OpenLR or WGS84 
Network Management type 


OO 0:0: OOO 


Intermediary 


As an Intermediary, | want to provide most accurate real time information on roadworks to the Service 
providers and road authorities by fusing their data, so that they can provide the most accurate data to 
their end systems. 


e | collect roadworks information from various sources. This is an existing service for road 
authorities, and a new service for Service Providers. 
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I monitor the data and fuse data where needed and/or extend the data sets. 

| detect newly reported Road Works and add them to the data set with a new UUID. 

Based on input from service providers | add a probability for the Road Works information. 

| produce a Common Road Works Picture which is provided to Service Providers and Road 
Authorities and the Assessor. 


Identified Interface: TMeX between Intermediary — Use Case partners 
Format of interface supplied is either JSON or XML. By choice of partners 


e Objects exchanged: 

Location of event (openLR & WGS84) 

Unique Event_ID 

Version (new version when features of traffic event change, e.g. extra lane closed). 
description of traffic event 

Freetext (textual description of traffic event) 
Heading (direction of traffic event) 

Location Wgs84 

Starttime (YYMMDDHHMMSSZ (UTC)) 
Endtime (YYMMDDHHMMSSZ (UTC)) 
Probability 

Number of sources reporting event 

Detection method (Manual, System, User Input) 
Quality Index 


o0000000000000O0 


Assessor 


The assessor shall determine the rate of quality improvement based on the delivered data per SP and 
RA and the fused result. Assessment shall be done based on data completeness, timeliness and 
probability rate. For this the user feedback loop will be used where possible. 


6.2 Functional overview 


They aim of the use case has been to determine whether fusion of different RW sources can help in 
creating a current view of Road Works as established in Activity 3. In order to do this, within Activity 4 
a data harvesting and fusion process has been built by MAPtm. This process gets with a set interval 
data from all providing partners and fuses the data into a harmonized view of current roadworks. This 
fusion is mainly done on the aspects of time and space and where possible on descriptive information 
as well. During this fusion and harvesting process the goal has also been to ‘wash’ the data and rid it 
of identifying elements with which the providing source can be identified in the current data view 
provided to all partners as a result of this fusion process. 


Within Socrates 2.0 the use case ‘Road Works’ as deployed within the pilot sites Antwerp, Munich and 
Amsterdam focusses on creating a common ground truth. This common is generated on data from all 
partners and shared with all partners providing data. Data is retrieved from the various partners and 
data providers within the project. These partners are TomTom, HERE, Be-Mobile and the government 
bodies Bayerisch Verkeersambt (Germany), Vlaamse Overheid (Belgium) and NDW (The 
Netherlands). The data is retrieved from these parties in their current form. On the providing side, all 
systems have been left unchanged. For the use case implementation, and the stated research 
questions, it was explicitly chosen to not alter current data provisions from the partners. Partially to 
save time but mostly to establish to what the added value could be in the current environment. 


First goal was to combine the retrieved data from the partners and provide a new message set with 
actual roadworks and provide a quality indication to the road work messages based on combining the 
same messages of a Road Works from the different partners. The content of the combined message 
set was aligned with the partners within Socrates. The message set was built upon the TMex 
principals, for data exchange, developed within the project. 
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If successful a next step would be a fusion of Road works based on multiple notifications of the same 
roadwork by the partners. This fusion would not only combine on time and location information but 
would also combine all available detail information and meta data for the provided Road Works into a 
‘most complete data set’. It must be stated that 100% completeness is only achievable in theory. 


6.3 Active partners and roles 


Two Socrates?- partners and one associated partner are active in the Road Works use case in 
Munich. 


FIGURE 26. PARTNERS AND ROLES IN THE MUNICH ROAD WORKS USE CASE 


Partner Role in use case 


Bavarian Road Authority Data provider / Road Authority 
(associated partner) 


MAPtm Intermediary 
MAPtm Assessor 
TomTom End user Service provider 


6.4 Description of end user services 


There where no, identifiable end user service specifically made or facilitated for the resulting data. The 
data has been processed, viewed and analysed and where possible integrated in current Road Works 
services delivered in many ways from the separate Service Provider’s and the Road Authority to the 
road user. 
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7. INFORMATION ARCHITECTURE - RW 


7.1 Sequence diagram 





Roadworks Munich Sequence Diagram 


| Ron sensor | [A 














Ptormed & Active RW (NDW) 


= = 
e Planned & Activa RW (NDW) "oi ` 


ZW dered 
ci tom FO 








User Cortert RW 





FIGURE 27: SEQUENCE DIAGRAM ROAD WoRKS MUNICH 


7.2 Processes and interactions 
MAPtm — NETWORK MONITOR 


e STEP 1: All data providing partners gather data from their underlying sources. For SP’s this is 
from their APP’s, in-car systems and third party supplying data sources. For the Road 
Authority this from their planning system and from road side safety equipment deployed at 
Road Works sites. 

e STEP 2: Network Monitor receives all data by pulling the data from the SP’s and RA. All data 
is stored in a centralised system and harmonised in preparation for the fusion process. 
Included in the harmonisation step is making sure data is not easily linked back to their 
providing sources. 

e STEP3: Data is fused based on common fields and when matches are found with a limited 
discrepancy. 

e STEP4: The fused data is made available on a REST API which, per request response with a 
XML or JSON formatted current view of active Road Works. 


7.3 Data storage for evaluation 
MAPtm - NETWORK MONITOR 


For evaluation purposes the fused data (API response) is stored per time interval, being ruffly 15 
minutes without ‘partner labelling information’. 
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8. SYSTEM ARCHITECTURE — RW 


8.1 


System / Application overview 


From the fusion process data is injected into the existing MDM-DATEX2 feed that is being provided by 
the Bavarian TMC within the pilot site. From the fusion process a new container is appended to the 
MDM-DATEX2 structure per updated Roadworks object within the existing feed. The old and updated 
information will coexisted alongside each other. Based on the probability rate a user of the feed can 
determine on his own business rules if and what part of the data will be used in their end systems. For 
objects that are new for the data feed, a roadworks light container will be appended to the existing 
feed as a new Roadworks object. Use-case users (SP’s and RA’s) do not have to amend their 
receiving systems for roadworks. Determining which roadworks info to take from the datasets can be 
done on their own terms. 


8.2 


Interfaces 


FIGURE 28: INTERFACE ALLSITES-RW-CM3, INFORMATION CAN BE PULLED 












name INT1 INT2 type definition 


location OpenLR Pe ee TI 
location WG584 RT Potenz I [| 






Comment 
Need Lëeeegt — | 


requirement 








Meta 


onal record cre DATETIME versioning 


F f EECH 
D 


Situational record version VARCHAR 














Network Management type x VARCHAR 2 


















Situational record first supplier 
x VARCHAR ? 


version time 


Probability of occurrence 


x INT 


UUID x UUID Unique ID 
Type of Roadworks x TEXT or INT moving, stationary, long-term 


lanes closed/available x TEXT or INT status of lane availability 


x TEXT or INT lanes wit reduced width 


Deag EE 


Temporary Traffic Light Signals 
koppeg fs = gei 


TEXT on INT in use or Traffic Warden 
. Traffic is divert to the other side 
Counterflow traffic x TEXT or INT 
of the road 


Passable for emercency services 


















copy from datexll? 
copy from datexll? 
already available certain/probable/riskOf 
is certain is definitief (change van starttime) 


Traceability Z 


>Groupoflocation boom 
0 = open, 1 = closed, sequence f pi 
o 
number for lane postition on road 
> impact 
ei >OperatorActions - 
P RoadorCarriageWaytManagement 
Do we need this? Can we get this 
from a different datexil container for | SpeedManagement 
this location? 
A d GeneralNetworkManagement > 
TLC for controlling one lane traffic i i 
trafficManuallyDirectedBy 


alternating traffic over one lane 


o S $ ReRoutingManagement (in NL verplicht 
Copy from input. Avaliable in p 
S om andere route op te geven als gebruikt 
lantwerp/munich? 
wordt) 


RoadOrCarriageManagement > 
useOfSpecifiedLanesAllowed 
(wegafgesloten voor alles behalve) 












(validity aangeven met period) 














Changed Traffic Situation Road Layout has changed 


Author x TEKST or INT Alert created by 



















for changes in longer term RW 
dependable on whether this is 


Source 
allowed 





For all pilot sites (Amsterdam, Antwerp, Munich) the Road Works URL-endpoints are formatted in a 


unified structure; 


https://roadworks.maptm.nl/{pilotsite}/{responseformat}/ 


The variables within the URL are: 


e PILOTSITE: This can either be; Amsterdam, Antwerp, Munich 
e RESPONSEFORMAT: This can either be; TMEX or JSON. 


Road Works data identified in the fusion process to not be within the provided RA MDM-DATEX2 feed 
will be injected into the existing and supplied MDM-DATEX2 feed and rebroadcasted with an extra 
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container for added information from the Socrates?- project. Original and updated/added information 
will co-exist in this feed. 


FIGURE 29: EXAMPLE OF A RW FEED 


"s2@ tmexid": 136514, 

"s20 creationtime": "2019-12-17T18:30Z", 
"s28 updatetime": "2019-12-17T18:30Z", 
"s2@ endtime": null, 

"s2@ version": 1, 


"s20 isactual": true, 


"roadname": "Camera Obscuralaan", 
"locationdescription": "Camera Obscuralaan", 
"directiondiscription": "Construction work:Camera Obscuralaan, between Klaasje Zeve 


nsterstraat and Oranjebaan", 
"impactdelay": null, 
"location_wgs84": "LINESTRING(4.87716 52.303272,4.876755 52.302063)", 
"location_fordisplay": "POINT(4.87716 52.303272)", 
"alertccountrycode": null, 
"alertctableid": null, 
"alertcttrafficcode®": null, 
"alertcdescription®": null, 
"alertcduratione": null, 
"alertcdirection®": null, 
"alertcttrafficcode1": null, 
"alertcdescription1": null, 
"alertcduration1": null, 
"alertcdirection1": null, 
"planned_startdatetime_rw": "2019-12-17T18:14Z", 
"actual_startdatetime_rw": null, 
"detected_datetime_rw": null, 
"situationalrecordversion": null, 
"generalnetworkmanagementtype": null, 
"situationalrecordfirstsuppliertime": null, 
"number_ofoccurences": null, 
"probability_ofoccurences": "Probable ", 
"probability_rate": null, 


"type_ofroadworks": "CONSTRUCTION", 
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"numberoflanesrestricted": null, 
"numberofoperationallanes": null, 
"originalnumberoflanes": null, 
"roadclosed": false, 
"temporaryspeedlimit": null, 
"onelanetrafficcontrol": null, 
"counterflowtraffic": null, 
"detourinformation": null, 
"passableforemercencyservices": null, 
"changedtrafficsituation": null, 


"author": "Socrates 


Every data feed of the partners was aligned with dataset (TMex) for the Road Works that was agreed 
upon and where useful information was added if one of the partner’s data feed had specific useful 
information. Error! Reference source not found. shows the contents ofthe RW-TMex message. As 
the table shows the list of fields is rather straight forward without nesting information in 
(sub)containers. Many data fields are already available in varying degrees within the data feeds 
provided as sources for this use case. 


FIGURE 30: TMEX MESSAGE SET 


Response field Name Type definition Comment 
s20_tmexid VARCHAR Socrates 20 uuid 
an 5 TE Within 
s20_creationtime Integer First creation time TETEN 
: : ; Within 
s20_updatetime timestamp Last update time AENOR 
7 timestamp ; Within 
s20_endtime Detected end time framework 
4 timestamp ; Within 
s20_ version Version of message EE 
s20_isactual boolean Message is current 
roadname VARCHAR Streetname 
locationdescription VARCHAR descriptive text for 
location information 
directiondiscription VARCHAR orientation of RW 
impactdelay Integer Time lost due to RW ee 
- location OpenLR openLR 
location _wgs84 location WGS84 Linestring 
location_fordisplay location for display (WGS84) POINT 
alertccountrycode from alertC when available VARCHAR 
alertctableid from alertC when available Integer 
alertcttrafficcode0 from alertC when available Integer 
alertcdescriptionO from alertC when available VARCHAR 
alertcdurationO from alertC when available VARCHAR 
alertcdirectionO from alertC when available VARCHAR 
alertcttrafficcode1 from alertC when available Integer 
alertcdescription1 from alertC when available VARCHAR 
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alertcduration1 
alertcdirection1 
planned_startdatetime_rw 
actual_startdatetime_rw 
detected_datetime_rw 
situationalrecordversion 
generalnetworkmanageme 
nttype 
situationalrecordfirstsuppl 
iertime 
number_ofoccurences 
probability_ofoccurences 
probability_rate 


type_ofroadworks 
numberoflanesrestricted 
numberofoperationallanes 


originalnumberoflanes 


not available currently, 
planned for future 
incorporation 


roadclosed 
temporaryspeedlimit 


onelanetrafficcontrol 


counterflowtraffic 


detourinformation 
passableforemercencyser 
vices 


changedtrafficsituation 
author 


Data harmonisation 


from alertC when available 
from alertC when available 
Planned Start datetime RW 
Actual start datetime RW 
Detected datetime RW 
Situational record version 


Network Management type 


Situational record first 
supplier version time 
Number of data suppliers 
reporting the same RW 


Probability of occurrence 
Probability rate 


Type of Roadworks 


lanes closed/available 
Number lanes opened for 
traffic during RW 

Number of lanes opened for 
traffic during normal 
operation 


Narrow Lanes 


Reduced speed 


one lane traffic control 


Counterflow traffic 


Detour information 
Passable for emercency 
services 


Changed Traffic Situation 
Author 


VARCHAR 
VARCHAR 
timestamp 
timestamp 
timestamp 
Integer 


VARCHAR 
VARCHAR 
Integer 
VARCHAR 
REAL 


VARCHAR 
Integer 
Integer 


Integer 


TEXT or INT 


boolean 
Integer 


boolean 


boolean 
VARCHAR 
boolean 


VARCHAR 
VARCHAR 


Start time of Road works 
Reported Start time 
This is NOT a start time 


Number of sources 
reporting some RW 

rate for RW are to be 
seen on the road 

rate for trueness of RW 
info 

moving, stationary, long- 
term 

status of lane availability 
Number of lanes 
available 

Number of lanes 
available in normal 
situation 


lanes wit reduced width 


Road closed due to road 
works 


Temporary Traffic Light 
Signals in use or 
Traffic Warden 

Traffic is divert to the 
other side of the road 


Road Layout has 
changed 
Alert created by 


When available 
When available 


During the matching stage of de data feeds of the partners towards the TMex message set, it was 
striking how much the shape and the contents differed per feed, provider and even between sites (e.g. 
DATEX2). So, for every feed for every site the code to retrieve and convert to the Socrates dataset 
(TMex) was rewritten and adapted. Feeds differ in complexity, from a compact and straightforward 
dataset with actual road works to complex DATEX2 data sets including not only actual roadworks but 
also planned or even past events. Moreover, the naming and coding (e.g. containers or not) of the 
fields differs per feed. This is also regarding TMC and DATEX2 standardised fields as well. 


Differences in georeferencing 


e TMC is not harmonic over all sites. The implementation of the TMC principle divers per 


site/country and thus has had its particularities per site. 


e Documentation for TMC is only available for paying members of TISA. Beyond that a current 
TMC table must be retrieved from the relevant governing bodies and isn’t available as open 
data everywhere. Though, payment is never required for obtaining the TMC tables. 

e Service Providers use different geospatial projections. But in most cases provided alternative 
projections within the feed. 

e The Flanders data feed is provided with only TMC as geospatial reference. 

e Relying solely on TMC geospatial referencing limits the area where RW can be reported as 
TMC is not covering all roads (e.g. local and residential roads). This difference is especially 


visible between Public and Private sources. 
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Differences in data provision 


e DATEX2 has proven not harmonic over all sites 

e Detail information is not consistent added 

e Update intervals are not always clear and never in sync. 

e DATEX2 feed from NDW was too large for a stable feed. To get a good performance Extra 
RAM memory was allocated on the NDW side and we used a cut out from the region of 
Amsterdam. 
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9. OPERATIONAL PILOT 


9.1 Recruitment 


Initially the operational period was planned from January 2020 to June 2020. 


The Road Works use case went live in December 2019. But a targeting and recruitment of specific 
users was not necessary. 


For the Smart Destination use case a targeting of user groups started in autumn 2019. In parallel, 
starting from November 2019 till October 2020 friendly users tested the different development steps. 


9.2 Impact of Corona - SD 


Because of the Corona crisis big events like soccer games and trade fairs had been skipped from end 
of March 2020. Therefore, the Munich Socrates2.02.0 operational period was extended to end of 
2020. The hope was that some bigger events may be possible in autumn 2020 again. Realising in 
summer 2020 that no big events will be realistic in 2020 in Munich, no further effort had been spent in 
recruitment. 


To get feedback, live tests with friendly users had been executed, as described following. 


10. ANALYSIS - SD 


The tests for the Use Case Smart Destination in Munich had been organized as follows. 


Participants: 


e Bavarian Road Authority 
e BrandMKRS 
e BMW 
e Be-Mobile 
Structure: 


e Testphase 1: provide strategies on the MDM (functional design) 

o Strategies towards the Allianz Arena and the Messe München are made be available 
on the national access point MDM by the Bavarian Road Authority. 

o Even in times of no event is taken place in the Allianz Arena or the Messe München, 
the “base” strategy is active and processed to the MDM by the Bavarian Road 
Authority. 

e Testphase 2: internal service set-up (functional design) 

o Service Providers process (synthetic) strategies within their own system and adapt 
their route/ guidance advice accordingly. 

o Friendly users are partly used to gain detailed feedback. 

e Testphase 3: Access MDM (integration test) 
o Service Provider establish a connection to the Munich strategies on the MDM. 
e Testphase 4: independent chain tests (integration test) 

o Service Provider access the strategies on the MDM, process them in their system and 
generate the user advice. Because the base strategy is always active and available 
on the MDM, this chain test could be done independently by each partner. 

o Friendly users are partly used to gain detailed feedback. 

e Testphase 5: Live Tests (joint integration test) 

o Even if there is no event taken place (due to the Corona Crisis), the Bavarian Road 
Authority activates different strategies in a scheduled way. This is done live via the 
Munich Traffic Management Centre, so that also the road side signs (VMS) are 
adapted and in parallel the activated strategies communicated to the MDM. 

o The live test focus only on the Messe München strategies. 
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o The Service Provider access the strategies on the MDM, process them in their internal 
System and send out an advice to some friendly users. 


The following aspect should be checked by the different tests: 


Are the strategies described correctly in the MDM-DATEX2 Format? 

Are the strategies available on the MDM? 

Do the messages arrive at the service providers? 

Do the correct messages arrive at the service providers? 

Can the messages be processed by the service providers? 

How does the generated information to the user look like? 

Is the generated information correct (time, location) and understandable by the user? 
Does this information correspond to the strategy that was send out by the BayRA? 


11. FINDINGS AND RELATED EVALUATION 
REPORT 


The evaluation of the Munich pilot and the drawn conclusions based on the analysis is not part of this 
report, but can be found in the evaluation report of Activity 8. Here just the main findings: 


A learning from the pilot site Munich is, that standardization should not be underestimated. Even 
though DATEX II is a Europeanwide standard, the regional different ways of filling and using the 
protocol raise implementation effort and impede faster large scaling. This also includes improving (the 
integration of) different forms of georeferencing. 

A one-way communication of public traffic management strategies is only a first step towards 
interactive traffic management. An important condition for future large scale implementation is the 
availability of such data, both standardized and through a national access point. 


Another insight from pilot site Munich is that service providers need the cause of a traffic management 
strategy (insight into the reason why) to point out the additional value of the service to the user. Make 
data as the public traffic management strategies available is no guarantee that service providers can 
process it beneficial for the user. The win-win-win must be further elaborated for this. 
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